IGMP Snooping
Published: 2022-08-05
IGMP Snooping is a switch feature that allows an Ethernet switch to participate in IGMP and use the information gathered to reduce unnecessary multicast flooding. If the switch doesn't participate, multicast traffic will be flooded out on all ports just like broadcast packets, wasting network resources.
IGMP snooping requires that a router port is assigned on the switch. The port is assigned whenever a port receives an IGMP general query, as the incoming port the query was received is the path towards the multicast router. So when R1 sends its general query, SW2 receives it on its E1 port, making E1 the SW2 snooping router port. SW2 then floods the query out on all other ports, allowing SW3 to assign its E2 port as the router port. You can scroll down to see the network topology.
IGMP Snooping features
Let's go through the features that snooping gives us:
-
IGMP Querier
Because of how important assigning a router port is, a switch can be configured as an IGMP Querier, generating IGMP queries if the network router can't generate them. It is very important to have some device generating IGMP queries for IGMP Snooping to work correctly.
-
Report Processing
By processing the membership reports sent by the multicast receivers, SW2 and SW3 quickly learn what multicast traffic each interface should be forwarded out on, reducing multicast flooding. Once the report has been processed, the switch forwards it out on its router port, further reducing the flooding otherwise caused by IGMP. This overrides the IGMPv2 host delay behavior as reports are not sent to other receivers, but the benefits make up for it.
-
Report Proxy
Also called Report Suppression. In this mode, the switch generates its own IGMP queries that it sends out on all non-router ports. When the query comes from the upstream multicast router, the switch can immediately reply with a report based on its own local snooping table entries. This reduces the amount of reports from hosts that might otherwise be generated, and it reduces the number of reports sent to the multicast router. A possible drawback may be some propagation delay.
Another benefit of the Report Proxy is that Group Leave message are suppressed by the switch unless the message was received on the last interface in the interface list; there is no reason for the switch to forward the message upstream if other local interfaces want to continue receiving the traffic.
Default snooping behavior is to only perform report processing, allowing the switch to learn which multicast traffic each interface wants to receive. You can add on the Querier and Proxy features if you need it.
Network topology
The last octet of each node IP-address is the same as its ID. PC4 has IP-address 10.0.0.4/24, SRV10 has 10.10.10.10/24.
Demo time!
The rest of this post will focus on how PIM, IGMP and IGMP Snooping cooperate to only forward multicast traffic where it's wanted. SW2 and SW3 are both Arista vEOS devices, all other devices run Cisco IOS. I will be using debug commands to the best of my ability, but the Arista debugging is a bit more involved than on Cisco, so output may not always be as clean as one would want.
SRV10 multicast generator
We start off by having SRV10 generate traffic to 239.1.1.1 using the ping command. At the same time, R1 has PIM enabled, triggering it to send IGMP queries to SW2, allowing it to assign its router port.
SRV10#show running-config
interface Ethernet0/0
ip address 10.10.10.10 255.255.255.0
---
SRV10#ping 239.1.1.1 repeat 1000
Sending 1000, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
..
R1#show running-config
interface Ethernet0/0
ip address 10.10.10.1 255.255.255.0
ip pim dense-mode
!
interface Ethernet0/1
ip address 10.0.0.1 255.255.255.0
ip pim dense-mode
---
R1#show ip mroute
IP Multicast Routing Table
(*, 239.1.1.1), 00:01:12/stopped, RP 0.0.0.0, flags: DP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.10.10.10, 239.1.1.1), 00:01:12/00:01:47, flags: PT
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list: Null
SW2(config)#trace IgmpSnooping filename snooping.log
SW2(config)#trace IgmpSnooping enable Igmp* all
SW2(config)#hostname SW2
SW2(config)#trace monitor IgmpSnooping
--- Monitoring /tmp/snooping.log ---
IgmpSnoopingPacket Processing a V2 query
IgmpSnoopingCore New multicast router 10.0.0.1 (multicastRouterTypePim) on Ethernet1
IgmpSnooping Flooding to entire VLAN except Ethernet1
The R1 output show that the traffic from SRV10 has generated two multicast routing table entries; one (*, G) entry and one (S, G) entry specifically for this ICMP traffic. As the list of outgoing interfaces is empty, R1 is dropping the packets.
The SW2 output show that it has received a general query and assigned its E1 interface as the router port. The output on SW3 is identical (E2 router port) and therefore not shown here.
PC4 join multicast group 239.1.1.1
Let's see what happens when PC4 joins the (*, 239.1.1.1) multicast group. We are mostly interested in R1 and SW1 as they are running IGMP and IGMP Snooping, respectively.
PC4(config-if)#ip igmp join-group 239.1.1.1
IGMP(0): Send v2 Report for 239.1.1.1 on Ethernet0/0
SW2(config)#trace monitor IgmpSnooping
--- Monitoring /tmp/snooping.log ---
IgmpSnoopingPacket Processing a valid V1 or V2 report
IgmpSnoopingPacket group: 239.1.1.1, intf: Ethernet4, reporter: 10.0.0.4, version: IGMPv2
IgmpSnooping Adding Ethernet4 to mcast group 01:00:5e:01:01:01 for vlan 1
IgmpSnooping Flooding to RouterInterface Ethernet1
---
SW2(config)#show ip igmp snooping groups
Vlan Group Type Version Port-List
--------------------------------------------------------------------------------
1 239.1.1.1 Dynamic - Et1, Et4
IGMP(0): Received v2 Report on Ethernet0/1 from 10.0.0.4 for 239.1.1.1
IGMP(0): Received Group record for group 239.1.1.1, mode 2 from 10.0.0.4 for 0 sources
IGMP(0): MRT Add/Update Ethernet0/1 for (*,239.1.1.1)
---
R1#sh ip mroute
(*, 239.1.1.1), 00:19:49/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Dense, 00:03:30/stopped
(10.10.10.10, 239.1.1.1), 00:19:49/00:02:54, flags: T
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Dense, 00:03:30/stopped
SRV10#ping 239.1.1.1 repeat 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
..............
Reply to request 490 from 10.0.0.4, 1 ms
Reply to request 491 from 10.0.0.4, 1 ms
Reply to request 492 from 10.0.0.4, 1 ms
Starting with PC4, we can see that it joins the 239.1.1.1 group and generates a report message. SW2 receives this report and creates a new group entry in its IGMP Snooping table, adding E4 to the list of outgoing interfaces. This is how the switch knows which interfaces should receive the multicast traffic. SW2 finally forwards the IGMP report from PC4 out on its router port to R1.
R1 receives the IGMP report and updates its multicast routing table, adding E0/1 to the list of outgoing interfaces for the two 239.1.1.1 entries. On SRV10 we see that PC4 is now responding to the ping packets.
PC6 join multicast group 239.1.1.1
Let's throw PC6 (connected to SW3) into the mix and see what output is generated this time:
SW3(config)#trace monitor IgmpSnooping
--- Monitoring /tmp/snooping.log ---
IgmpSnoopingPacket Processing a valid V1 or V2 report
IgmpSnoopingPacket group: 239.1.1.1, intf: Ethernet6, reporter: 10.0.0.6, version: IGMPv2
IgmpSnooping Adding Ethernet6 to mcast group 01:00:5e:01:01:01 for vlan 1
IgmpSnooping Flooding to RouterInterface Ethernet2
---
SW3(config)#show ip igmp snooping groups
Vlan Group Type Version Port-List
--------------------------------------------------------------------------------
1 239.1.1.1 Dynamic - Et2, Et6
SW2(config)#trace monitor IgmpSnooping
--- Monitoring /tmp/snooping.log ---
IgmpSnoopingPacket Processing a valid V1 or V2 report
IgmpSnoopingPacket group: 239.1.1.1, intf: Ethernet3, reporter: 10.0.0.6, version: IGMPv2
IgmpSnooping Adding Ethernet3 to mcast group 01:00:5e:01:01:01 for vlan 1
IgmpSnooping Flooding to RouterInterface Ethernet1
---
SW2(config)#show ip igmp snooping groups
Vlan Group Type Version Port-List
--------------------------------------------------------------------------------
1 239.1.1.1 Dynamic - Et1, Et3, Et4
R1#debug ip igmp
IGMP(0): Received v2 Report on Ethernet0/1 from 10.0.0.6 for 239.1.1.1
IGMP(0): Received Group record for group 239.1.1.1, mode 2 from 10.0.0.6 for 0 sources
IGMP(0): MRT Add/Update Ethernet0/1 for (*,239.1.1.1) by 0
SRV10#ping 239.1.1.1 repeat 10000
Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Reply to request 1 from 10.0.0.4, 6 ms
Reply to request 2 from 10.0.0.4, 9 ms
Reply to request 3 from 10.0.0.4, 6 ms
Reply to request 4 from 10.0.0.4, 9 ms
Reply to request 5 from 10.0.0.4, 6 ms
Reply to request 6 from 10.0.0.4, 6 ms
Reply to request 6 from 10.0.0.6, 10 ms
Reply to request 7 from 10.0.0.4, 23 ms
Reply to request 7 from 10.0.0.6, 25 ms
Reply to request 8 from 10.0.0.4, 5 ms
Reply to request 8 from 10.0.0.6, 9 ms
SW3 and SW2 output is very similar to what we've seen before. They receive the membership report and add the interface the report was received on to its list of outgoing interfaces for that multicast group. The big change is that SW2 now forwards to 239.1.1.1 traffic to SW3, it did not do this before.
R1 receives the report from PC6 and refreshed its multicast entry timers. SRV10 now receive ping replies from both PC4 and PC6, verifying that the multicast traffic is going the whole way.
PC6 239.1.1.1 Group Leave
Let's see what happens when PC6 leave the 239.1.1.1 multicast group.
SW3(config)#trace monitor IgmpSnooping
--- Monitoring /tmp/snooping.log ---
IgmpSnoopingPacket Processing a valid V2 leave
IgmpSnooping Removed Ethernet6 from mcast group 01:00:5e:01:01:01 on vlan 1
IgmpSnooping Flooding to RouterInterface Ethernet2
R1#debug ip igmp
IGMP(0): Received Leave from 10.0.0.6 (Ethernet0/1) for 239.1.1.1
IGMP(0): Received Group record for group 239.1.1.1, mode 3 from 10.0.0.4 for 0 sources
IGMP(0): Lower expiration timer to 2000 msec for 239.1.1.1 on Ethernet0/1
IGMP(0): Send v2 Query on Ethernet0/1 for group 239.1.1.1
IGMP(0): Received v2 Report on Ethernet0/1 from 10.0.0.4 for 239.1.1.1
This is the output generated when PC6 left the group. SW3 processes the leave message, removing E6 from the list of outgoing interfaces. In fact, the whole group is removed from the IGMP snooping table, but I couldn't find any corresponding log message to show this actually happening. Sorry.
SW2 also processes the leave message, removing Ethernet3 from its list of interfaces and forwards the leave message to R1. R1 receives the leave message and sends out a group-specific query checking if others want to continue receiving the traffic, which PC4 does.
Communication Diagram
Using this sequence diagram, we can see how IGMP Join (membership report) messages affect how far the multicast traffic from SRV10 is allowed to travel. At first, R1 discard all packets because its list of outgoing interfaces is empty for that multicast group.
Once PC4 has sent its Join message to R1 via SW2, the traffic is allowed by R1 and filtered by SW2 so that PC4 is the only receiver.
When PC6 sends its Join message, SW2 learns that the traffic also should be forwarded to SW3, duplicating the multicast packets, sending one copy to PC4 and another to SW3. SW3 then makes sure that only PC6 receives the traffic and not PC7.
Conclusion
This has been a look into the IGMP Snooping protocol and how it interacts with IGMP. There are still plenty of things for you to learn, I haven't covered either IQMP querier or Report Proxy in any detail and I have only been focusing on IGMPV2 in this post. Thanks for reading!